OpenEdge Development:<br />Progress Dynamics Advanced Development Understanding the Object Tables in the Progress Dynamics Repository

This chapter describes those elements of the Progress Dynamics Repository that make up the definition of application objects, which includes:

Procedural objects such as SDO logic procedures, custom super procedures, and business logic procedures (PLIPs).

Object types and the class hierarchy that defines a SmartObject.

SmartObjects, both static and dynamic (though detailed information is stored in the Repository only for dynamic objects).

Object instances as used on a particular container.

Object attributes (properties).

SmartObject links that define the communication path between objects.

Page layouts and folder pages.

Like other chapters in OpenEdge Development: Progress Dynamics Advanced Development , this one observes a convention of using the word Object with a capital O to denote an application component that has attributes and specialized behavior associated with it. Not all of these things are in fact SmartObjects. Database fields are represented in the Repository as DataField objects, and although these are not SmartObjects, they have attributes defined in the Repository that extend their behavior beyond simple widget objects such as buttons and ordinary fill-in fields. Procedures registered in the Repository are also objects with extended behavior beyond ordinary operating system procedures. Their relative pathnames and other information are stored in the Repository, allowing the framework to access and manage them more effectively.

While this chapter does not describe any one specific product feature, the information provided should serve as a basis for understanding all the framework features that either populate the object tables in the Repository (such as the Entity Import tool, the Object Generator, etc.) or read the information at run time to realize the application. It can also be used as a guide to anyone developing new tools and procedures that must read or write to the Repository.

The chapter describes the actual Repository tables and their fields in detail, in order to provide you with as complete an understanding of the Repository database as possible. However, you should always keep in mind as you read this material that Progress Dynamics includes an extensive API to provide both design-time and run-time access to the Repository, and any code you write that must use the Repository should always use this API, which will continue to be supported and kept compatible and consistent, even as changes are made over time to the underlying specifics of the data structure.

This material is of interest to Progress Dynamics application developers and is designed to help you to understand better how the framework operates. Remember that you can write complex and complete Progress Dynamics applications, including customizations and extensions to the framework and its object types, without ever writing a line of code that uses the Repository API, or accesses the Repository database directly. Knowledge of the Repository internals is of interest to those writing new tools to manage the Repository data in some way that goes beyond the support that is currently provided by the standard framework tools.

An example of this could be a custom migration tool that you build to convert your existing application, which, of course, has its own particular structure and architecture, into a Progress Dynamics-based application that is largely data-driven. Another example could be an application analysis tool that provides useful information to you about the structure of your application, such as a tool to analyze dependencies and provide you with information on the impact of changes, and so forth. Yet another example would be a new set of run-time driver procedures to read the data and create an interface for a new type of client platform.

Over time, the Progress Dynamics development team will endeavor to provide all developers with more useful tools of this type, but we will never be able to satisfy every user need, and we want you to be as independent as possible in your ability to provide yourself (and potentially others in the Progress community) with the tools you need to complete and manage your application.

The Progress Dynamics Repository database contains tables that support many functions, from the definition of application components to user maintenance, security definition, session and configuration management, message maintenance, translation, deployment information, and more. This chapter focuses on those tables that support the definition of application objects, in particular those that are represented only as data in the Repository and which are then realized dynamically at run time. The tables that are used in other parts of the framework, such as session management and the APIs that provide you with access to that information, are described in other documents, including OpenEdge Development: Progress Dynamics Managers API Reference and OpenEdge Development: Progress Dynamics Administration .

The discussion in this chapter is broken down into logical groups of related tables, though nearly all the tables involved are related to one another in some way. Much of the basis for this documentation is taken from the extensive internal documentation in the ERwin model for the Repository database, and the reader with access to ERwin can refer to the model directly for the complete picture of the Repository database and all its tables.

The following sections break down the object Repository into meaningful groups of related tables and discuss the nature of the data, how it can be generated, and how it is used at run time to realize a largely dynamic application: